Is this boundary reached in any situation?
Only the read operations require the boundary to be lifted ?
Which was the original purpose of this boundary ?

I believe the boundary was incorrectly hard coded to be 16MB for no particular reason. Perhaps at the time 16MB was the device size used to test the driver, but I'm not entirely sure as I am not the original author.

The boundary value is used to calculate how much data is left during a read operation, so clearly setting this to a hard-coded value is is not correct.

I tested this patch using a 32MB device. Read, write, and erase operations were all exercised at address ranges below and above 16 MB as well as at the upper memory boundary of the device.

Did you check CONFIG_SPI_FLASH_BAR ?
There is a menu inside u-boot menuconfig configuration for flashes above 16 MiB
As it looks to me, to have flashes higher capacity than 16 MiB , one needs to have more address bytes (4 bytes as it looks in the documentation), and this may be an issue with older flashes, etc.
As there is some support for higher than 16 MiB flashes in U-boot, is this change fixing this driver (namely this is a bug in u-boot core for this flash support ) ?

Hi Eugen, in looking at the code again, I mistakenly thought the #endif on line 562 was an #else which would have excluded the code when BAR support was enabled. This is extremely puzzling...during my debugging I did test BAR support but got bad data, or so I thought. I re-tested the unmodified branch with BAR support and see read/write operations happening correctly at the 16MB boundary and above.
Now I need to figure out what I was doing wrong the first time!

I will close this pull request. Thanks for the sanity checks!